In a mobile communication network, a user terminal may operate in secure mode or insecure mode. In secure mode, the user terminal applies security to the transmitted packets by ciphering or encrypting data packets transmitted to the network on the uplink traffic channels and control channels. On signaling channels, the user terminal also adds integrity protection to the transmitted data packets. In insecure mode, ciphering and integrity protection are turned off. The user terminal begins operation in secure mode when a network node (e.g., base station or MME) sends a secure mode command (SMC) to the user terminal.
Currently, the base station has no way of detecting when the user terminal begins secure transmission. Before the secure mode is started, the user terminal transmits unprotected data packets on the uplink. After the base station has transmitted the SMC, a user terminal may transmit one or more unprotected packets in the uplink before it has received the SMC or before the secure mode is activated by the user terminal. The base station has no way of distinguishing protected from unprotected data packets after the SMC has been transmitted to the user terminal.
The problem in detecting the start of secure mode by a user terminal may be solved by suspending all traffic from the user terminal before sending the SMC (see 3GPP RAN2 contribution R2-073466, Section 2.2, option 1), such that there is no unciphered and unprotected signaling on the uplink between the time the SMC is sent on the downlink and the time that the secure mode has been activated on the uplink. In this case, the first uplink signaling packet after the SMC is transmitted may be expected to be ciphered and integrity protected. The drawback with this approach, however, is that uplink transmissions have to be suspended for a while and, hence, some signaling may need to be postponed/delayed.
An alternative solution (see 3GPP RAN2 contribution R2-073466, Section 2.2, option 2) would be to include a flag in the packet header for all packets transmitted on the uplink to indicate whether secure the mode has been started at the user terminal. With this flag, the network may detect whether security has been started and process the packets accordingly; i.e., pass on unciphered data and decipher and/or integrity check data before passing it on, respectively. The drawback with this approach is that the flag, which is only needed at activation of security, introduces extra overhead, not only for the first few packets, but also for all packets sent after security has been activated.
A similar problem may occur when a user terminal changes security state after security has been started. For example, the user terminal may turn off the secure mode, or the security state may become invalid due to an impairment event. In the former case, the receiver would be unable to distinguish protected from unprotected data packets, while in the latter case the receiver would be unable to detect the security failure. In the case where header compression is used, the receiver would be unable to distinguish a security failure from a failure to decompress IP headers.
In the case where the secure mode is turned off, the problem may also be solved by suspending all traffic from the user terminal or by using a flag in the packet header. These solutions have the same drawbacks mentioned above. In the case where security fails, it is possible to detect the security failure by detecting whether the IP header is garbage or whether it represents a semantically correct IP header. However, when header compression is used, it is not possible for the receiver to distinguish between a failure to decompress the header and a security failure. There is too little data received and no part of the compressed information may be assumed to be static to allow this detection (redundancy between consecutive IP headers is removed). Therefore, there is no test for the case where header compression is used to distinguish between decompression failure and a security failure.